Managing Security Within the Database Engine : Database Security

1. Creating Database Users

Database users are one type of principal that you can grant permissions for accessing objects within the database. The permissions granted to a user will determine their capabilities within the database (we will talk about permissions later on in this chapter). Server principals have no rights in databases until you assign them to a database principal, and for the purposes of this discussion, that database principal is a database user.

Assigning server principals to database principals is not a complex task. You've probably done it naturally without thinking about the proper verbiage used to describe the process. Review the following syntax to see how you create a database user.

CREATE USER username
[ { {FOR | FROM}
   {LOGIN loginName
    | CERTIFICATE certificateName
    | ASYMMETRIC KEY asymmetricKeyName
  }
  | WITHOUT LOGIN
]
WITH DEFAULT_SCHEMA = schemaName

Using the preceding syntax, you create a database user by first supplying a name. Next, specify the server login name that you want to associate to the user. If you do not specify the server login name, then SQL Server will try to map the user to a server login with the same name. Instead of specifying the server login, you may instead associate the user to a certificate or asymmetric key. Finally, specify the schema that you want to associate to the user. If you do not specify the default schema, SQL Server will map the user to the dbo schema.

See the following code for an example of creating a database user for an existing server principal.

USE AdventureWorks2008
GO

CREATE USER apressSecurity
FOR LOGIN apressSecurity
WITH DEFAULT_SCHEMA = dbo
GO

Now, test the following code sample to easily combine the creation of a SQL Server login with the mapping of the database user.

USE master
GO

CREATE LOGIN apressReader WITH PASSWORD = 'P@ssw0rd!' ,CHECK_POLICY = ON,_
CHECK_EXPIRATION = ON,
DEFAULT_DATABASE = Adventureworks2008;
GO

USE AdventureWorks2008
GO

CREATE USER apressReader
FOR LOGIN apressReader
WITH DEFAULT_SCHEMA = dbo
GO

2. Database Roles

SQL Server 2008 supports two types of database roles: fixed and flexible roles. Fixed roles are the predefined database roles created by Microsoft for SQL Server. These roles cannot be modified. You can add database users to them, but you cannot (nor should you try to) change them.

Flexible roles are the roles you create to group users together, in terms of functionality that they perform, within your database. Generally, grouping database users together within a database role enables you to more easily control their permissions. From an administrative point of view, you should find it easier to define the permissions for the role and then add users to the role accordingly than to repeatedly define the same permissions for each user. That way, you can minimize the amount of time it takes to grant users access to the objects within the database.

2.1. Understanding Fixed Roles

Following is a list of the fixed database roles that are currently available:

• DB_Owner: Performs all configuration and maintenance tasks within the database.

• DB_SecurityAdmin: Modifies role membership and manages permissions.

• DB_AccessAdmin: Controls the addition and removal of access to the database for Windows users, Windows groups, and SQL Server logins.

• DB_BackupOperator: Possesses the ability to back up the database.

• DB_DDLAdmin: Contains the ability to execute data definition commands.

• DB_DataWriter: Inserts, updates, and deletes data from the tables in the database.

• DB_DataReader: Selects or reads data from the tables in the database.

• DB_DenyDataWriter: Restricts insert, update, and delete data from the tables in the database.

• Public: The default role database users are granted access to.

It is up to you to decide what fixed roles to grant users access to and what roles you may want to create. Microsoft's goal with fixed roles is to make it easy for you to delegate commonly performed administrative tasks to users.

2.2. Creating a Database Role

To create a database role, simply supply the name of the database role that you want to create. Then specify the permissions that you want the role to have. You can specify who owns the role by using the Authorization command, but by default, the user who creates the role owns it. The only remaining task comes from assigning database users to the role by using sp_addrolemember.

Often times, junior (JR) DBAs have restricted read-only access in your production environment because they are more prone to make costly mistakes than a seasoned DBA. However, you may want JR DBAs to have the ability to query database scoped Dynamic Management Views (DMVs) in order to perform analysis on the production databases, which requires more privileges than the db_datareader role permits. In this case, you can create a new database role for the JR DBAs instead of granting them access to the database using a fixed role.

Execute the code in Listing 1 to create a JR_DBA role and to grant the appropriate permissions to the role. Once you have created the role, you can assign users to it just as if it were a fixed role. Those users will then be able to query data from tables and retrieve data from database state DMVs.

Example 1. Creating a Role and Granting Execute Permissions

USE AdventureWorks2008
GO

CREATE ROLE JR_DBA
GO

GRANT VIEW DATABASE STATE,SELECT to JR_DBA
GO

3. Application Roles

An application role is a database principal that allows an application to connect to a database and perform actions according to the permissions of the role. Unlike other database roles, application roles do not allow you to add users to the role, and they are created with passwords. By default, application roles are disabled until an application connects to the database and supplies the application role's password.

Here's an example of creating an application role:

Use AdventureWorks2008
GO

CREATE APPLICATION ROLE authorApps
WITH PASSWORD = '@uth0rA@pp5@!'
GO

GRANT SELECT, UPDATE, INSERT , DELETE to AuthorApps
GO

Having created this role, you can enable it from an application by having that application execute the following stored procedure call:

exec sp_setapprole authorApps, '@uth0rA@pp5@!'

Your application supplies the password. The stored procedure checks that password against the one you specified when you created the role. If the password is correct, the stored procedure will enable the role, giving the application all the permissions that you have granted to the role. The permissions remain in effect for the duration of the session.